Fix logout race: clear partitioned cookies, recheck session on 401 - #4701

Summary

Fixes the intermittent logout race where a user is briefly bounced to sign-in, then reappears signed in as the previous account with a "Something went wrong" error on the listing page.

Problem

After logout, the framework session cookie was deleted without matching the Partitioned/SameSite=None attributes it was originally set with under CHIPS. A partition-blind delete removes the wrong jar, so the browser keeps sending the old session cookie. If an instance's cached session state still resolves that stale token, the app can briefly re-authenticate as the previous account. Separately, when a request came back 401 (server no longer recognizes the browser), nothing told the client session gate, so the app shell stayed mounted on a stale "authenticated" answer and data queries surfaced a bare "Something went wrong" instead of redirecting to sign-in.

Solution

• Make cookie deletion on logout mirror the exact attributes (including Partitioned) used when the cookie was set, so both the partitioned and unpartitioned jars are actually cleared.
• Add a throttled session re-check that triggers whenever an authenticated request comes back 401, letting the client re-resolve the true session state and redirect to sign-in instead of showing a generic error.

Key Changes

• deleteCookieFromEveryScope now applies crossSiteCookieAttrs(event) so cookie clears match the scope/partition they were set in; clearFrameworkSessionHintCookies updated accordingly.
• Added recheckSessionAfterUnauthorized() in use-session.ts: throttled (5s min interval) re-fetch of session state, skipped once signingOut has begun to avoid resurrecting a session mid-logout.
• use-action.ts calls recheckSessionAfterUnauthorized() on 401 responses (but not 403, which represents an authenticated caller being refused one specific action).
• Added regression tests covering: partitioned vs. unpartitioned cookie clearing on logout (HTTPS and plain-HTTP), session re-check on 401 vs. no-op on 403, throttling of repeated re-checks, and re-check being a no-op once sign-out has started.
• Added a changeset for @agent-native/core describing the cookie-partition fix and 401 re-resolution behavior.

Review follow-up (f6a26f72b)

Reviewer flagged that mirroring crossSiteCookieAttrs closed the partitioned jar but opened the mirror-image gap: a Partitioned-only delete cannot remove a cookie stored before CHIPS, or over plain HTTP on a host later served over HTTPS. Agreed and fixed — both variants are now emitted.

That needed a workaround. h3 dedupes set-cookie on name;domain;path and ignores Partitioned, but only sometimes: it computes the key from options when writing and re-parses the header when scanning, and the scan side never recovers domain. Probed directly:

deleteCookieFromBothPartitions re-appends the unpartitioned delete only when h3 actually evicted it, so it is correct under either behaviour.

The middle row is pre-existing — 0dc7290a3 emits the same shape — and harmless, because a browser applies Set-Cookie in order and the set is last. Deliberately not fixed here; asserted instead, so no future change can leave a delete after the set. That assertion caught a duplicate domain-scoped delete in my first attempt at this follow-up.

To clone this PR locally use the Github CLI with command gh pr checkout 4701

You can tag me at @BuilderIO for anything you want me to fix or change